-
Notifications
You must be signed in to change notification settings - Fork 177
Add REST plugin for user-defined policies #2631
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Realized that setting up this plugin as an external package is unnecessarily complicating the installation process. I'm going to change it so that it's more builtin the server code. |
A good place for a built-in server plugins would be to put them in May require renaming Let me know if you need help with refactoring. |
@Nadine-H, Do you think of writing the spec manually or generating it automatically? Automatic generation is highly preferable because spec models are regularly updated with new properties and it won't be practical to maintain manually written spec. |
Automatic generation for sure. I set up a local FastAPI server to test the rest plugin and will share the |
Adding documentation to the guides as well |
And regarding the documentation, I think we can generate the OpenAPI schema reference from the example plugin server and put it in the Reference->Plugins->Rest plugin similar to how the server OpenAPI is generated (https://github.com/dstackai/dstack/blob/master/scripts/docs/gen_openapi_reference.py). This could probably be done in a separate PR to limit the scope. |
raise ServerClientError(f"{PLUGIN_SERVICE_URI_ENV_VAR_NAME} is not set") | ||
|
||
def _check_request_rejected(self, response: SpecApplyResponse): | ||
if response.error is not None: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Theoretically error: ""
would cause a rejection; is that intended?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It shouldn't, I'll fix it and add additional tests for this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@r4victor should we not allow empty strings and cause a pydantic ValidationError? or just treat it as a "no error" case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@r4victor I implemented the first option so that plugin developers are aware if they mistakenly set the error to ""
, but happy to switch to the other option if you prefer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. I see some unresolved comments so if you're willing to address them, please do. I'm happy to merge once CI is passed.
Resolves #2630.
Key notes: